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(54) Management of event information data with a mobile communication device 



(57) In a system for managing event information da- 
ta with a mobile communication device (1 ) event entries 
are stored in a database (1 7) and parameterized at least 
with a category, time and (geographical and/or logically) 



location. 

Therefore a list of accessible events can be presented 
to the user of the mobile communication device (1) by 
querying the event database (17). 
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Description 

[0001] The present invention relates to a method for 
managing event information data, to a computer soft- 
ware program product for implementing such a method 5 
as well as to a mobile communication device having an 
event managing module. 

[0002] Different systems are known from the prior art 
filtering events according to the user's profile and the 
current date, e.g. by using personal agents. Further- 10 
more many static lists or events are e.g. available in the 
Internet. Furtheron, there are systems that allow to send 
event notifications and reminders to specific user 
groups. Finally, calendar systems allow to enter events, 
to organise events as well as to retrieve events. 1$ 
[0003] However, all known systems suffer of a plural- 
ity of different drawbacks. E.g. neither the location as- 
pect of an event nor the time aspect for travelling to the 
location of an event is considered. 

[0004] In view of these disadvantages it is the object 20 
of the present invention to propose a technique allowing 
a correlated time and position management of event in- 
formation. 

[0005] This object is achieved by means of the fea- 
tures of the independent claims. The dependent claims 25 
develop further the central idea of the present invention. 
[0006] According to a first aspect of the present inven- 
tion therefore a method for managing event information 
data is proposed. The current time in the position of a 
mobile communication device is inquired. Using the cur- 30 
rent time in position information to generate a template 
an event source such as e.g. an event database is que- 
ried. The event source contains events entries param- 
eterized by the category, time and location. Finally a list 
of accessible events is presented on the mobile com- 35 
munication device, wherein the list of accessible events 
is generated by means of the query. 
[0007] Optionally profile information on the user of the 
mobile communication device can be part of the tem- 
plate used for the query of the event source. *o 
[0008] At least for apart of the accessible events a 
transportation information for possible ways to get from 
the current position of the mobile communication device 
to an event location can be calculated and presented on 
the mobile communication device. *5 
[0009] The list of accessible events can be presented 
dynamically. In other words, the list of accessible events 
can be updated to generate a list of remaining accessi- 
ble events each time the user of the mobile communi- 
cation device accepts an event of the list. When gener- 50 
attng the updated version of the event list, the parame- 
ters (time, location, etc.) of events already accepted by 
the user are taken into account. 
[0010] Accessible events accepted by the user of the 
mobile communication device can be automatically 55 
transferred as entries to an electronic calendar file. 
[001 1] The user of the mobile communication device 
can create events for the list of accessible events and/ 



or for the event source (e.g. event database). 
[0012] This can e.g. be achieved by creating events 
manually by customising generic events proposed by 
the mobile communication device. 
[001 3] A learning mode be provided in which the mo- 
bile communication device learns event preferences of 
the user by evaluating the interaction with the user. 
[0014] The user can pre-configure standing orders for 
events such that corresponding events are automatical- 
ly selected when retrieved in the event source. 
[0015] The event entries of the event source can be 
generated automatically by searching a network such 
as e.g. the internet. 

[0016] According to a further aspect of the present in- 
vention a computer software program product is pro- 
posed implementing a method as said above when run 
on a mobile computing device. 
[001 7] According to a still further aspect of the present 
invention a mobile communication device with an event 
managing module is proposed. The event managing 
module comprises means for determining the actual 
time and the current geographical position of the mobile 
communication device. Furthermore means for query- 
ing an internal and/or external event source are present. 
The event source contains event entries parameterized 
by category, time and location. A query can be per- 
formed on the basis of a template, containing at least 
the current time and geographical position of the mobile 
communication device. Finally means for presenting a 
list of accessible events output by the querying means 
are provided. 

[001 8] The template used by the querying means can 
furthermore comprise profile information of the user of 
the mobile communication device. 
[001 9] Furthermore the mobile communication device 
can comprise a navigation module for calculating and 
presenting possible ways to get from the current position 
of the mobile communication device to the location of 
an event. 

[0020] Computing means can update the list of acces- 
sible events dynamically to generate a list of remaining 
accessible events each time the user of the mobile com- 
munication device accepts a proposed event from the 
list. 

[0021] Finally means for automatically transferring 
accessible events accepted by the user of the mobile 
communication device as entries to an electronic calen- 
dar file can be present. 

[0022] Further advantages, features and objects of 
the present invention will become evident for the man 
skilled in the art when the readings of the following de- 
tailed description of an embodiment taken in conjunction 
with the figures of the enclosed drawings. 

Figure 1 shows a schematic representation of a sys- 
tem of implementing the present invention, 

Figure 2 shows schematically the adaptation of the 
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events, and 

Figure 3 shows schematically a possible distribu- 
tion structure for implementing the present inven- 
tion. 5 

[0023] With reference to Figure 1 at first a system for 
implementing the present invention will be explained. 
[0024] To this objective at first some externs and im- 
pressions will be explained. An "event" in the sense of 10 
the present invention is a social gathering or activity 
which usually has a certain start time, a time duration 
and therefore also an end time. In contrast to meetings 
of another gathering of a number of people is important, 
but a purpose of the invent, which requires certain *5 
sources (e.g. a film projector, a certain location, etc.) 
which are available only at certain places. Therefore an 
event happens at a certain location. A user has to get 
to this location from the current location which usually 
takes some time. Furthermore resources like transpor- 20 
tation means maybe necessary. Events are attended by 
a certain number of people. Events can be described as 
a structure like: 

Event purpose, location, date, start time, duration, 
attendees. 25 
[0025] A "template" is an event specification which 
consists of a number of specified attributes. An example 
of a template is: 

"film performance", Hedelfinger Str. 61+5 km, 
24.10.00, 18:00 GMT 30 
[0026] A "query" is a task to select a synchronously,* 
i.e. while the user is waiting for the result. 
[0027] A "standing order" is a task to select events to 
inform the user about the occoms of these events as 
synchronously, i.e. while the user is disconnected to the 35 
system. 

[0028] Now, the components of a system for imple- 
menting the present invention will be explained for sev- 
erance to Figure 1. 

[0029] A query management module 1 2 manages the *o 
queries and standing orders of users. In case of a query, 
the query management module receives this task from 
a presentation adaptation and interaction module (PI- 
AM) 6, asks the event gathering module 9 for events 
fitting into the template of the task, and sends these 45 
events to a selection and ordering module 10. After hav- 
ing received the results from the selection and ordering 
module 10, the query management module 12 forwards 
them to the PIAM 6 for display on a mobile communica- 
tion's device. To allow some interaction steps, the query 50 
management module 12 stores all data concerning the 
query in order to react to the user's interactions. There 
are two possible interaction steps. If a user accepts 
events proposed by the system, these events are en- 
tered into the calendar module 5 and the query is re- 55 
processed by sending again the events to the selection 
and ordering module 1 0 etc. As there are now more time 
restrictions, the result returned from the selection and 
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ordering module 10 to the query management module 
10 might differ from the first step. If a user removes 
(waives) an event in the calendar module 5, the query 
management module 12 is notified and the query is re- 
processed to generate again new results returned from 
the selection and ordering module 10 to the query man- 
agement module 12. 

[0030] In the case of a standing order the query man- 
agement module 12 receives this task from the PIAM 6. 
It asks the event gathering module 9 to inform the query 
management module 1 2 in case of the occurrence of an 
event fitting into the template. The processing of this 
task is then stopped, but ail data concerning the task is 
stored in the query management module 1 2. As soon 
as the event gathering module 9 notifies the query man- 
agement 1 2 on the occurrence of corresponding events, 
the query management module 12 sends the events to 
the selection and ordering module 10, receiving in turn 
the result which is a list of accessible events. The query 
management module 12 asks the presentation adapta- 
tion and interaction module 6 (PIAM) to inform the user 
on the result using the means the user selected. 
[0031] Finally the query management module 1 2 for- 
wards view selection information from the PIAM 6 to the 
context management module 7 when appropriate. 
[0032] In the following the function of the event gath- 
ering module 9 will be explained. This component gath- 
ers events and delivers sets of events that match a given 
template. There are several possibilities for the event 
gathering module 9 to gather events. One is to search 
appropriate information sources when events are need- 
ed, e.g. by using a search engine in the Internet 3 by 
consulting event web pages in the Internet 3. Another 
possibility is to subscribe to appropriate event sources, 
such that the event gathering module 9 is informed on 
the occurrence of new events. In order to react queries 
quickly, the event gathering module 9 can proactively 
search information sources (Internet 3 etc.) even with- 
out already knowing tasks. Thereto it can employ an 
own event database 1 7 to store events. In order to allow 
third parties to directly insert events manually, the event 
gathering module 9 can offer a manual input interface 
14 to do so. 

[0033] In case of a query the event gathering module 
9 receives a template from the query management mod- 
ule 12 and answers it by returning a list of accessible 
events that fit into the template. In case of a standing 
order the event gathering module 9 receives a template 
from the query management module 12. As soon as the 
event gathering module 9 finds an event that fits into the 
template, it informs the query management module 12 
by returning a list of events that fit into the template. 
[0034] To fulfil its task the event gathering module 9 
can access a location database 8 in order to determine 
the location of and the distance to retrieved events. After 
having accessed the location database 8, every location 
entry in an event is extended by the geographic position 
of the location. Therefore the geographic position can 
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e.g. be stored along with the event entry in the event 
database 17. 

[0035] The location database 8 is able to associate 
positions to symbolic (logic) location data as provided 
in the events. Such an association can be e.g.: 

"Gloria 1" = 34.00078N, 4.8901W 134.3 Meter). 
[0036] The first string denotes the symbolic (logic) 
name. The second part contains the graphic position e. 
g. in the WGS 84 format. Symbolic (logic) names can 
include names a location is known under ("MOnchener 
HofbrSuhaus"), an address ("Hedelfingerstr. 61") and 
other references to locations. Symbolic (logic) names 
are delivered by the event gathering module 9. The lo- 
cation database 8 answers such a request with the cor- 
responding geographic position. 
[0037] Now the function and operation of the selection 
ordering module (SOM) 1 0 will be explained. This com- 
ponent gets a set of events from the query management 
module 12 and selects and orders events aeon to a set 
of attributes. It answers to the query management mod- 
ule 12 by returning an ordered list of events. The set of 
attributes is requested of the context management mod- 
ule 7. It consists of an open set of data like: 

• User preferences like 

event categories 
■ key words 

- names of preferred participants (and their 
roles) 

- preferred locations 

• open time/location slots. 

[0038] In order to determine the time distance of and 
the way to events, the selection and ordering module 1 0 
can access the navigation module 11. It requests these 
data by delivering the a start in target location of possible 
transportation means. 

[0039] A description of the way and an estimation of 
the time needed in returned from the navigation module 
7. 

[0040] Navigation module 11 is connected to a posi- 
tion determination means such as e.g. a GPS. The po- 
sition determination means 15 can be furthermore con- 
nected to the query management module 12. The nav- 
igation module 11 can compute path to go from location 
to another one, resulting in a description of the way and 
the time necessary given a set of possible transportation 
means. 

[0041] The Context Management Module 7 gathers 
and stores context data and delivers them to the SOM 
10 in order to configure the selection and ordering proc- 
ess and to the PIAM 6 in order to configure the presen- 
tation adaptation and the interaction process. Context 
data might include: 

• the location of the user 



• data and time at the location of the user 

• the temperature at the location of the user 

• personal user data like his/her schedule 

• the history of his/her service usage 

5 • the actual condition of the network the user con- 
nects to 

• the actual condition of the user device 

• the user profile (e.g. age, gender, nationality, and 
user preferences) 

10 • the abilities of the user device 

• the social situation the user currently experiences. 

[0042] Parts of these data are collected from the CM 
5. 

*5 [0043] When in "learning mode" the CMM 7 tries to 
gather user profile information automatically by exam- 
ining the interactions of the user with the service (see G 
in Figure 1 ), and , when possible, also by watching other 
Internet usage of this user outside the service. This in- 

20 formation is again stored inside the CMM 7. 

[0044] To allow users to use different sets of context 
data (e.g. to have different preferences according to the 
mode (business trip or holiday journey)), context data 
sets can be organised into different "views". The user is 

25 able to select these views using the PIAM 6 (which in- 
forms the QMM 12, which finally informs the CMM 7 
about the currently selected view). When delivering con- 
text information, the currently selected view is used. 
[0045] The Presentation Adaptation & Interaction 

30 Module PIAM 6 presents the results of queries and 
standing order to a user. This presentation is adapted 
according to context data like: 

• Type of the used device 

35 • the actual condition of the network 

• and so on 

[0046] Additionally, the PIAM 6 allows the user to do 
the following things: 

40 

• enter a new request 

The user can specify all relevant attributes and 
modes of presentation (e.g. concerning sorting etc.) 
This results in a query that is sent to the QMM 12. 

45 

• enter a new standing order 

The user can specify all relevant attributes. 
This results in a query that is sent to the QMM 12. 

so • modify a standing order 

This is done by requesting a standing order 
from the QMM 12 and let the user modify it. The 
standing order is then resent to the QMM 12. 

55 • watch the results of requests or standing orders 

• accept an event of an event list 

In case of acceptance, the event is entered into 
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the CM 5, then the QMM 12 is notified in order to 
get a new result that considers the new time/loca- 
tion restrictions that result from that choice. 

• select a view 5 

• select notification means 

[0047] Additionally, the PIAM 6 is able to send notifi- 
cations to offline users when the system detected an n> 
event that fits into a standing order. 
[0048] The calendar module 5 presents a calendar- 
like presentation to the user. Events the user has ac- 
cepted are entered into this calendar. In case of e.g. a 
change of mind or when exploring alternatives, a user 15 
can also waive accepted events in the calendar. In this 
case, the Query Management Module 12 is informed. 
To integrate into an existing office environment, the cal- 
endar module can be an existing product (e.g. Microsoft 
Outlook) as long as other programs can enter events 20 
and as long as other programs can sense the removal 
of events in the calendar. 

[0049] Additionally, the calendar is one source of in- 
formation for the context management system. 

25 

Flows inside the system 
A query is processed 

[0050] The user starts a query process at the PIAM 6. 30 
The user enters a query at the PIAM 6, thus specifying 
e.g. the date, time, and location of the events to get. The 
PIAM 6 produces a template out of that and sends it, 
together with other data (e.g. presentation options, and 
the view to use) to the QMM 12. The QMM 12 creates 35 
a query entry and stores it. Afterwards, it sends the tem- 
plate to the EGM 9. The EGM 9 gathers events that fit 
into that template, e.g. by using its internal database. It 
also uses the LD 8 to determine whether an event fits 
into the template. Finally, it extends the events that fit *o 
into the template with the geographic positions gathered 
from the LD 8. This set of events is returned back to the 
QMM 1 2, where it is stored in the query entry. The QMM 
12 sends this set to the SOM 10. The SOM 10 applies 
its selection and ordering algorithm using data gathered 45 
from the CMM 7. To determine, in which time events can 
be reached, the SOM 10 uses the NM 11 which also 
delivers a description of the ways to reach the event. 
This description also extends the events. The SOM 10 
then returns an ordered list of events back to the QMM 50 
12. The QMM 12 sends this list to the PIAM 6, where it 
is presented to the user by applying the presentation ad- 
aptation mechanisms using context data from CMM 7. 
[0051] The user is now able to accept events from that 
list or remove events in the calendar. 55 
[0052] After having finished the query, the user stops 
the query process. 



The user accepts an event 

[0053] If the user accepts an event in the PIAM 6, the 
event is sent to the CM 5 where it is entered into the 
calendar of that user. Additionally, the PIAM 6 sends the 
acceptance notification to the QMM 12, which in turn 
starts the selection and ordering process by sending the 
SOM 10 the set of event received before from the EGM 
9, but where the accepted event has been removed. As 
the accepted event further restricts the time/location 
availability of the user, another list of events might result 
from this process (the SOM 10 will know of this restric- 
tion as it receives these context data from the CMM 7, 
which, in turn, queries the CM 5). As above, the new list 
of events is presented to the user, and the user again 
can accept an event. 

The user waives an event 

[0054] Events in the CM 5 (i.e. accepted events) can 
be waived by the user at any time. In this case the event 
is removed from the user's calendar by the CM 5. If no 
query is currently processed, no further steps are taken. 
If currently a query is processed and the waived event 
is one that originated from that query, this event is sent 
to the QMM 12 and the whole query process is re-start- 
ed. The only difference is that the event is again added 
to the event set stored at the QMM 12. If currently a que- 
ry is processed and the waived events does not origi- 
nate from that query process, the complete query proc- 
ess is started again by the QMM 12, i.e. also the EGM 
9 is asked for events that fit into the query template. 

A standing order is entered 

[0055] The user specifies a standing order at the PI- 
AM 6 in a similar way as he/she specifies a query with 
the one difference that also the communication means 
is specified that shall be used to inform the user about 
the occurrence of a corresponding event. The PIAM 6 
then sends this standing order to the QMM 12, where a 
standing order entry is generated. Finally, the QMM 12 
sends the corresponding template to the EGM 9. 

A standing order is processed 

[0056] If the EGM 9 finds one or more events that fit 
to the template of the standing order (using the LD 8 in 
the same way as with queries), it sends these events to 
the QMM 12, specifying the standing order they belong 
to. The QMM 12 then starts the selection and ordering 
process in the same way as in the query process. When 
the QMM 12 sends the event list to the EGM 9, it also 
adds the communications means specification selected 
by the user. Finally, the user is notified about the event 
list using the selected communications means by the 
EGM 9. The user is then able to connect to the system 
and to interact in the same way as during a query (i.e. 
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accepting and waiving events). 

[0057] In the following data structures for the system 

will be explained. 

[0058] One data structure is the event and event tem- 
plate, respectively, as they determine which kinds of 5 
events can be found. As described above, events mainly 
consist of 6 elements, namely: 

• event purpose 

• location 10 

• date 

• start time 

• duration 

list of attendees 

15 

where the event purpose might be described with a 
standardised language (ontology). The location can be 
described either by a geographic position or a symbolic 
name that can be replaced by the LD 8 with a geographic 
position. 20 
[0059] Event templates have to offer possibilities to 
specify these elements in a fuzzy way. Per element, 
these possibilities include, apart from let an element un- 
specified (denoted by an "*"): 

25 

Event purpose 

[0060] Here the problem is that we may have general 
and more specialised categories like "performance" - 
"opera". Therefore we need something like a tree of cat- 30 
egories, so an event can be described by higher-level 
categories. Additionally, some purposes should be de- 
scribed by several categories, therefore we need a list 
of categories describing an event. 
[0061] It is obvious that we need parameters for this 35 
element, for e.g. specifying a certain film (like "Casa- 
blanca"). 

Location 

40 

[0062] This element contains the geographical posi- 
tion of the event. 

[0063] Additionally, this element may contain an 
"threshold*" attribute that specified the range of x me- 
ters around this data for events that fit into that template. 45 

Date 

[0064] This element contains the date of the event. 
[0065] Additionally, this element may contain an so 
"threshold*" attribute that specified the range of x days 
around this data for events that fit into that template. 

Start time 

55 

[0066] This element contains the start time of events. 
If have to make sure that also the time zone of this time 
is encoded in order to prevent miscalculations. 



[0067] Additionally, this element may contain an 
"threshold*" attribute that specified the range of x sec- 
onds around this data for events that fit into that tem- 
plate. 

Duration 

[0068] This element contains a duration e.g. in min- 
utes. 

[0069] Additionally, this element may contain an 
"threshold*" attribute that specified the range of x sec- 
onds around this data for events that fit into that tem- 
plate. 

List of attendees 

[0070] This element contains references to persons. 
Ordering 

[0071] Each of the elements above might additionally 
contain an "orderingm" attribute that denotes that this 
element shall also be used for order the event set. The 
parameter n of this attributes denotes the rank of the 
ordering element. 

Examples of event templates 

[0072] What to do now and here? 

(event purpose=*; 

location=ORDER:1,34.7894N.85993W.374m,thresh- 
old: 10000m; 
date= 19.10.00; 

start=ORDER:2,13:41 MET threshold: 3600sec; 
duration=ORDER:3, *; 
list of attendees = *) 

[0073] Planning of a day out in Paris 

(event purpose =*; 

location=ORDER:1,17.7894N.81.993W.374m,thresh- 
old: 10000m; //was "Paris.Boulevard St. Germain" 
date = 15.11.00; 

start=ORDER:2,8:00 MET, threshold: 36000sec; 
duration=ORDER:3,*; 
list of attendees=*) 
[0074] A true fan 

(event purpose = Music Performance of "The Jellyba- 
bies"; 

location = ORDER: 1,34. 7894N.85.993W.374m,thresh- 

old: 50000m; 

date="; 

start="; 

duration = *; 

list of attendees = *) 

Specification of queries and standing orders 

[0075] The easiest way to implement this aspect is 
certainly to offer the user an interface where he/she can 
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specify every single element with all the given possibil- 
ities. Unfortunately, this would require the knowledge of 
how to specify these things. Therefore, this possibility is 
only suited for expert users. Additionally, especially mo- 
bile devices like mobile phone normally do offer only 
very restricted input possibilities (as they rarely include 
a keyboard and feature only small displays). 
[0076] Normal users or users using this type of devic- 
es can use a restricted interface that allow to choose 
only of a few possibilities. One of these possibilities is 
the "what to do now and here" mode, where the system 
generates a template as described above using the cur- 
rent time and location taken from the CM M (which, in 
turn, might have sensed these information at the user's 
device). 

[0077] The easiest way to interact with the system is 
to allow active suggestions based on implicitly gathered 
profiles as then the user does not have to further specify 
queries or preferences. Another possibility to help users 
specifying queries and standing order is to use default 
values also stored in the CMM. 

Gathering events: 

[0078] Events can be entered directly via manual in- 
put. In this case all relevant information can be gathered 
easily using an appropriate form. 
[0079] Events can be also gathered by searching ap- 
propriate information sources, e.g. web pages, e-mails 
(if this is appropriate under privacy aspects), and data- 
bases. Especially in the web, there are many pages that 
offer event data in a human-readable form, e.g. http:// 
www.stuttgart.de/sixcms/list.php37page id =25. There 
are also some databases in the Internet, e.g. httg://www. 
lift-online.com/cg i/setkalender.pl where event data can 
be queried automatically. As there is no standard for of- 
fering such data, and as the audience for event data is 
normally a human one, most information sources fea- 
ture an own event data format, often suited for human 
use. Therefore, an architecture that wants to use these 
information sources has to cope with the different for- 
mats, which might be also the subject of frequent, un- 
announced changes. The EGM 9 has then simply to 
translate the event data format of the information sourc- 
es to the one used in the system. 
[0080] In the near future, such events might be offered 
on sources like web servers as XML documents. In this 
case, the EGM has to know and to understand the cor- 
responding DTDs. 

[0081] Events are stored into an event database 17 
inside or outside of the EGM 9, e.g. in XML form, in order 
to quickly react on queries by the QMM 12. 

Getting events from the EGM 

[0082] To return a set of events that fit into a given 
event template, the EGM 1 2 has to consider all elements 
of an event template. An element qualifies for being in- 



cluded in the event set, all of its elements have to qualify. 
An element qualifies if it is unspecified ("*"). Whether a 
specified element qualifies, depends on the element: 

5 Event purpose 

[0083] This element qualifies if the specified category 
is a predecessor in one of the category hierarchies of 
the event, and if the parameter, if specified, are equal. 

10 

Location 

[0084] This element qualifies if the geographical loca- 
tion of the event (as determined by the LD 8) lies in the 
15 range specified by the event template. 

Date 

[0085] This element qualifies if the date of the event 
20 lies in the range specified by the event template. 

Start time 

[0086] This element qualifies if the date of the event 
25 lies in the range specified by the event template. 

Duration 

[0087] This element qualifies if the date of the event 
30 lies in the range specified by the event template. 

List of attendees 

[0088] This element qualifies if the fist of persons 
35 specified in the event template are contained in the list 
of attendees of the event. 

Selection and Ordering Algorithm 

40 [0089] The selection and ordering algorithm is a two- 
stage process. In the first stage events out of the incom- 
ing event set are selected according to some criteria re- 
ceived from the CMM determined by a view selected by 
the user. One of these criteria is the calendar of the us- 

45 ers: only events are selected that do not collide with ex- 
isting entries. Another criteria is the time needed to 
reach the location of an event. Computed by the NM 11, 
this time need is considered when events are selected 
that fit into the time range of the event template. 

so [0090] In the second stage, the events are ordered ac- 
cording to the ordering criteria. These criteria are spec- 
ified in the event templates. 

Presentation adaptation 

55 

[0091] The presentation is adapted inside the PIAM 6 
towards the user in relation to a whole number of factors. 
The presentation process consists of at least three stag- 
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es (see Figure 2) 

[0092] The first stage is the "data adaptation" which 
adapts the presentation according to the characteristics 
of the data (i.e. the events) itself. If an event is e.g. near- 
by, just the event description and the location of the 
event might be displayed, if an event is not nearby, but 
in the same city, additionally the public transport data 
(time tables, ways to a station) is displayed, etc. These 
adaptation can be realised e.g. by using a rule mecha- 
nism that is able to specify things like "if (event.location 
= "nearby") then show (event.desription, event.loca- 
tion)" or "if (eventlocation = "intown") then show (event, 
description, event, location, event, transportation, time- 
tables)". 

[0093] The second stage is the "user adaptation" 
which adapts the presentation in relation to the user. 
This includes adjustments according to the explicit set- 
tings by the user, his/her preferences that have been 
learned by the system, etc. 

[0094] The third stage is the "device adaptation" 
which adapts the presentation according to the charac- 
teristics of the actual user device and the data connec- 
tion to that device. This adaptation includes adjustments 
to things like the screen size, the colour abilities, the 
needed presentation format (e.g. HTML or WML), the 
actual bandwidth, and the condition of the network. 
[0095] The components of the system could be dis- 
tributed as depicted in Figure 3. The PIAM 6 component 
can be decomposed into a system-side PIAM module 
6, and a user-device-side client program 4. The latter 
might consist simply of a web or a WAP browser. Alter- 
natively, it might consist of a special client program that 
handles interaction of the user with the system. The CM 
5 might reside on the user device; in this case it might 
consist of an existing calendar program (like Microsoft 
Outlook). 

[0096] The overall system can be realised as a serv- 
ice of a multi-access service portal. 
[0097] The EGM 9 gathering process can be realised 
using translator and adaptor components that translate 
events from the format at the source into the format that 
is used inside the system, and that encapsulate the que- 
rying process of the event source, respectively. It can 
be expected that events can be accessed in the web in 
an XML-based format in the future. 
[0098] The EGM 9 can employ a SQL database to 
store the events gathered. The Event templates can 
then be realised by SQL statements that are used to be 
executed in the EGM database. 
[0099] The CM 5 can be located either on the user's 
device, in the system, or on another computer in a con- 
nected network. The CM 5 can be e.g. realised using 
Microsoft Outlook using its COM interface on the user's 
device. 



Claims 

1. Method for managing event information data, 
the method comprising the following steps: 

5 

inquiring the current time (1 6) and the position 
(15) of a mobile communication device (1), 

- using the current time (16) and position (1 5) in- 
formation for a template to query (12) an event 

10 source (9), the event source (9) containing 

event entries parameterized by their category, 
time and location, and 

- presenting (6) a list of accesible events on the 
mobile communication device (1), wherein the 

* 5 list of accessible events is generated by means 

of the query (12). 

2. Method according to claim 1 , 
characterized in that 

20 furthermore profile information of the user of the 
mobile communication device (1 ) is part of the tem- 
plate to query (12) the event source (9). 

3. Method according to claim 1 or 2, 
25 characterized in that 

at least for a part of the accessible events a trans- 
portation information for possible ways to get from 
the current position of the mobile communications 
device (1 ) to an event location is calculated (11 ) and 
30 presented. 

4. Method according to anyone of the preceding 
claims, 

characterized in that 

35 the list of accessible events is presented (6) dynam- 
ically, i.e. the list of accessible events is updated to 
generate a list of remaining accessible events each 
time the user of the mobile communication device 
(1 ) accepts an event. 

40 

5. Method according to anyone of the preceding 
claims, 

characterized in that 

accessible events accepted by the user of the mo- 
« bile communication device (1) are automatically 
transferred as entries to an electronic calendar file 
(5). 

6. Method according to anyone of the preceding 
50 claims, 

characterized in that 

the user of the mobile communication device (1) 
can create events for the list of accessible events 
and/or for the event source (9). 

55 

7. Method according to claim 6, 
characterized in that 

the user can create (14) events by customizing 



8 



15 



EP 1 241 830 A1 



16 



manually generic events proposed by the mobile 
communication device (1). 

8. Method according to anyone of the preceding 
claims, 5 
characterized by 

a learning mode in which the mobile communication 
device (1 ) learns event preferences of the user by 
evaluating the interaction with the user. 

10 

9. Method according to anyone of the preceding 
claims, 

characterized in that 

the user can preconfigure standing orders for 
events such that corresponding events are auto- *5 
matically selected when retrieved in the event 
source (9). 

10. Method according to anyone of the preceding 
claims, 20 
characterized in that 

the event entries of the event source (9) are gener- 
ated automatically by searching a network (3). 

11. Computer software program product, 25 
characterized in that 

it implements a method according to anyone of the 
preceding claims when run on a mobile computing 
device (1). 

30 

12. Mobile communication device having an event 
managing module, 

the event managing module (1, 2) comprising: 

means (1 5, 1 6) for determining the actual time 35 
and the current geographical position of the 
mobile communication device (1), 
means for querying (12) an internal and/or ex- 
ternal event source (9) containing event entries 
parameterized by their category, time and loca- *o 
tion, wherein the querying is performed on the 
basis of a template containing at least the cur- 
rent time and geographical position of the mo- 
bile communication device (1 ), and 
means for presenting (6) a list of accessible 45 
events being output by the querying means 
(12). 

13. Mobile communication device according to claim 

12, 50 
characterized in that 

the template used by the querying means (12) fur- 
thermore comprises profile information of the user 
of the mobile communication device (1 ). 

55 

14. Mobile communication device according to claim 12 
or 13, 

characterized in that 



it furthermore comprises a navigation module (11) 
for calculating and presenting possible ways to get 
from the current position of the mobile communica- 
tion device (1 ) to the location of an event. 

15. Mobile communication device according to anyone 
of claims 12 to 14, 

characterized by 

a computing means (6) for updating the list of ac- 
cessible events dynamically to generate a list of re- 
maining accessible events each time the user of the 
mobile communication device (1 ) accepts an event. 

16. Mobile communication device according to anyone 
of claims 12 to 15, 

characterized by 

means (12) for automatically transferring accessi- 
ble events accepted by the user of the mobile com- 
munication device as entries to an electronic calen- 
dar file (5). 



15 



20 



25 



30 



35 



9 



EP 1 241 830 A1 



FI61 





-17 



Event 
Gathering 
Module 



query 
events 




return 
events 



collect data 



L 



Presentation 
Adaptation & 
Interaction 
Module 



R \ i Query 
° Management 



n 




configure 



Y return 
12 results 
10 




Position 




Navigation 


determination 




Module 


N . 


\ 


15 


11 



10 



EP 1 241 830 A1 



FIG 2 





device 




user 




data 




adaptation 




adaptation 




adaptation 



set of 
events 



user device 



FIG 3 

WTD system 




Internet 


13- 

\ 




/ event source 


- event source 


- event source 


v event source 


v event source 


s event source 





T 



11 



EP 1 241 830 A1 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



Application Number 

EP 01 10 6565 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



CRatlon of document wttti Indication, where appropriate, 
of relevant passages 



Relevant 
to claim 



CLASSIFICATION OF THE 
APPLICATION flnt.CI.7) 



X 

Y 



Y 
A 



WO 97 41654 A (MCLORINAN ANDREW GEORGE 
;TS0UKAS GEORGE JAMES (AU); ERICSSON 
TELEF) 6 November 1997 (1997-11-06) 



* page 

* page 

* page 

* page 

* page 

* page 

* page 

* page 8 

* page 

* page 



9 

10, 



1 - line 13 * 

2 - line 15 * 

line 26 - page 4, line 5 * 
line 18 - line 29 * 
4 - line 10 * 
30 - page 6, line 7 * 
line 30 * 
line 26 * 
line 17 - line 28 * 

page 11, line 5 * 



line 
line 



line 

line 

line 27 - 

line 20 
ine 17 
line 29 



1-11 



12-16 



H04L12/28 
H04Q7/22 



EP 0 924 916 A (SIEMENS AG) 
23 June 1999 (1999-06-23) 

* column 2, line 40 - line 45 * 

* column 3, line 39 - line 51 * 

* column 4, line 3 - line 42 * 

* column 5, line 18 - line 29 * 

* column 5, line 57 - column 6, line 6 * 

WO 98 08314 A (GINIGER MICHAEL L ; HILTON 

WARREN SCOn (US)) 

26 February 1998 (1998-02-26) 

* page 1, line 11 - line 20 * 
10, line 5 - line 31 * 

line 
line 31 
line 7 - 
line 
line 
line 



1 

12 



TECHNICAL FIELDS 
SEARCHED (lnLCI.7) 



12-16 
1-3,11 



H04Q 
H04L 



* page 

* page 12, 

* page 15, 

* page 16, 

* page 18, 

* page 20, 

* page 22, 



6 - line 32 * 
line 34 * 
line 10 * 
1 - line 17 * 
30 - line 31 * 
20 - line 27 * 



The present search report has been drawn up for all claims 



THE HAGUE 



Oats of comptetJon of the search 

16 October 2001 



Heinrich, D 



CATEGORY OF CITED DOCUMENTS 

X : particularly relevant If taken alone 

Y : particularly relevant H combined with another 

document of the same catei — 
A : technological background 
O : non-written disclosure 
P : Intermediate document 



T : theory or principle underlying the Invention 
E : earOer patent document, but published on, or 

after the filing date 
D : document ctted In the application 
L : document ctted for other reasons 

& : member of the same patent family, corresponding 
document 



12 



EP 1 241 830 A1 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



Application Number 
EP 01 10 6565 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document wtth Indication, where appropriate, 
of relevant passages 



Relevant 
to claim 



CLASSIFICATION OF THE 
APPLICATION (lntCI.7) 



US 6 157 841 A (ROSEN KENNETH H ET AL) 
5 December 2000 (2000-12-05) 

* column 1, line 13 - line 25 * 

* column 3, line 16 - line 20 * 

* column 3, line 62 - column 4, line 3 * 



TECHNICAL FIELDS 
SEARCHED (tnt.CI.7) 



The present search report has been drawn up for all claims 



THE HAGUE 



Oats crt oofnptsOon of the ■eftfoh 

16 October 2001 



Exam ire r 

He1nr1ch, 0 



CATEGORY OF CITED OOCUMENTS 

X : particularly relevant rf taken alone 

Y : particularly relevant If combined with another 

document of the same category 
A : technological background 
O : non-written disclosure 
P : Intermediate document 



T : theory or principle underlying the Invention 
E : earfler patent document, but published on, or 

attar the tiling date 
D : document cited In the application 
L : document cited tor other reasons 



& : member o1 the same patent family, corresponding 
document 



13 



EP 1 241 830 A1 



ANNEX TO THE EUROPEAN SEARCH REPORT 
ON EUROPEAN PATENT APPLICATION NO. 



EP 01 10 6565 



This annex lists the patent family members relating to the patent documents cited In the above-mentioned European search report 
The members are as contained In the European Patent Office EDP fle on 

The European Patent Office Is In no way liable for these particulars which are merely given for the purpose of Information. 

16-10-2001 



Patent document 




Publication 






Patent family 


Publication 


cited In search report 




date 






members) 


date 


WO 9741654 


A 


06-11-1997 


AU 


2375097 A 


19-11-1997 








WO 


9741654 Al 


06-11-1997 








EP 


0864211 Al 


16-09-1998 


EP 0924916 


A 


23-06-1999 


DE 


19756851 Al 


01-07-1999 








EP 


0924916 A2 


23-06-1999 


W0 9808314 


A 


26-02-1998 


US 


6199045 Bl 


06-03-2001 








WO 


9808314 Al 


26-02-1998 


US 6157841 


A 


05-12-2000 


NONE 







For more details about this annex : see Official Journal of the European Patent Office, No. 12/82 



14 



(19) 



J 



Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 



(12) 



(11) EP 1 241 830 B1 

EUROPEAN PATENT SPECIFICATION 



(45) Date of publication and mention 
of the grant of the patent: 
27.10.2004 Bulletin 2004/44 



(51) tot CI J: H04L 12/28, H04Q 7/22 



(21) Application number: 01106565.3 

(22) Date of filing: 15.03.2001 



(54) Management of event information data with a mobile communications device 

Verwaltung von Ereignisinformationsdaten mit einem mobilen Kommunikationsgerat 
Gestion de donnees d'information d'evenement avec un dispositif de communication mobile 



CD 
o 

CO 
00 



CL 
Hi 



(84) Designated Contracting States: 

AT BE CH CY DE DK ES Fl FR GB GR IE IT LI LU 
MC NL PT SE TR 

(43) Date of publication of application: 
18.09.2002 Bulletin 2002/38 

(73) Proprietor: Sony International (Europe) GmbH 
10785 Berlin (DE) 

(72) Inventors: 
• Kovacs, Erno, 
c/o Sony International Europe) GmbH 
70327 Stuttgart (DE) 



• Hohl, Fritz, c/o Sony International Europe) GmbH 
70327 Stuttgart (DE) 

(74) Representative: Rupp, Christian, Dipl.Phys. et al 
Mitscherlich & Partner 
Patent- und Rechtsanwalte 
Sonnenstrasse 33 
80331 Miinchen (DE) 



(56) References cited: 
EP-A- 0 924 916 
WO-A-98/08314 



WO-A-97/41654 
US-A-6157 841 



Note: Within nine months from the publication of the mention of the grant of the European patent, any person may give 
notice to the European Patent Office of opposition to the European patent granted. Notice of opposition shall be filed in 
a written reasoned statement. It shall not be deemed to have been filed until the opposition fee has been paid. (Art. 
99(1 ) European Patent Convention). 



Printed by Jouve. 75001 PARIS (FR) 



1 



EP 1 241 830 B1 



2 



Description 

[0001] The present invention relates to a method for 
managing event information data, to a computer soft- 
ware program product for implementing such a method 5 
as well as to a mobile communication device having an 
event managing module. 

[0002] Different systems are known from the prior art 
filtering events according to the user's profile and the 
current date, e.g. by using personal agents. Further- 10 
more many static lists or events are e.g. available in the 
Internet. Furtheron, there are systems that allow to send 
event notifications and reminders to specific user 
groups. Finally, calendar systems allow to enter events, 
to organise events as well as to retrieve events. *s 
[0003] However, ali known systems suffer of a plural- 
ity of different drawbacks. E.g. neither the location as- 
pect of an event nor the time aspect for travelling to the 
location of an event is considered. 

[0004] In view of these disadvantages it is the object 20 
of the present invention to propose a technique allowing 
a correlated time and position management of event in- 
formation. 

[0005] WO 97/41654 discloses a telecommunication 
and information dissemination system for a disseminat- 25 
ing information to subscribers of a mobile telecommuni- 
cations network from at least one information source 
containing data which is updated continuously or at in- 
tervals. 

[0006] WO 98/08314 shows a method and apparatus 30 
for providing position-related information to mobile re- 
cipients. 

[0007] This object is achieved by means of the fea- 
tures of the independent claims. The dependent claims 
develop further the central idea of the present invention. 35 
[0008] According to a first aspect of the present inven- 
tion therefore a method for managing event information 
data is proposed. The current time in the position of a 
mobile communication device is inquired. Using the cur- 
rent time in position information to generate a template <o 
an event source such as e.g. an event database is que- 
ried. The event source contains events entries param- 
eterized by the category, time and location. Finally a list 
of accessible events is presented on the mobile com- 
munication device, wherein the list of accessible events <s 
is generated by means of the query. The accessible 
events are calculated taking into account the differences 
between the starting time and the location of an event 
and the current time and position of the mobile commu- 
nications device. so 
[0009] Optionally profile information on the user of the 
mobile communication device can be part of the tem- 
plate used for the query of the event source. 
[0010] At least for apart of the accessible events a 
transportation information for possible ways to get from 55 
the current position of the mobile communication device 
to an event location can be calculated and presented on 
the mobile communication device. 



[001 1] The list of accessible events can be presented 
dynamically. In other words, the list of accessible events 
can be updated to generate a list of remaining accessi- 
ble events each time the user of the mobile communi- 
cation device accepts an event of the list. When gener- 
ating the updated version of the event list, the parame- 
ters (time, location, etc.) of events already accepted by 
the user are taken into account. 
[001 2] Accessible events accepted by the user of the 
mobile communication device can be automatically 
transferred as entries to an electronic calendar file. 
[001 3] The user of the mobile communication device 
can create events for the list of accessible events and/ 
or for the event source (e.g. event database). 
[0014] This can e.g. be achieved by creating events 
manually by customising generic events proposed by 
the mobile communication device. 
[001 5] A learning mode be provided in which the mo- 
bile communication device learns event preferences of 
the user by evaluating the interaction with the user. 
[001 6] The user can pre-configure standing orders for 
events such that corresponding events are automatical- 
ly selected when retrieved in the event source. 
[0017] The event entries of the event source can be 
generated automatically by searching a network such 
as e.g. the Internet. 

[001 8] According to a further aspect of the present in- 
vention a computer software program product is pro- 
posed implementing a method as said above when run 
on a mobile computing device. 
[001 9] According to a still further aspect of the present 
invention a mobile communication device with an event 
managing module is proposed. The event managing 
module comprises means for determining the actual 
time and the current geographical position of the mobile 
communication device. Furthermore means for query- 
ing an internal and/or external event source are present. 
The event source contains event entries parameterized 
by category, time and location. A query can be per- 
formed on the basis of a template, containing at least 
the current time and geographical position of the mobile 
communication device. Finally means for presenting a 
list of accessible events output by the querying means 
are provided. 

[0020] The template used by the querying means can 
furthermore comprise profile information of the user of 
the mobile communication device. 
[0021] Furthermore the mobile communication device 
can comprise a navigation module for calculating and 
presenting possible ways to get from the current position 
of the mobile communication device to the location of 
an event. 

[0022] Computing means can update the list of acces- 
sible events dynamically to generate a list of remaining 
accessible events each time the user of the mobile com- 
munication device accepts a proposed event from the 
list. 

[0023] Finally means for automatically transferring 
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accessible events accepted by the user of the mobile 
communication device as entries to an electronic calen- 
dar file can be present. 

[0024] Further advantages, features and objects of 
the present invention will become evident for the man 5 
skilled in the art when the readings of the following de- 
tailed description of an embodiment taken in conjunction 
with the figures of the enclosed drawings. 

Figure 1 shows a schematic representation of a sys- 10 
tern of implementing the present invention, 

Figure 2 shows schematically the adaptation of the 
events, and 

Figure 3 shows schematically a possible distribu- 
tion structure for implementing the present inven- 
tion. 

[0025] With reference to Figure 1 at first a system for 
implementing the present invention will be explained. 
[0026] To this objective at first some extems and im- 
pressions will be explained. An "event" in the sense of 
the present invention is a social gathering or activity 
which usually has a certain start time, a time duration 
and therefore also an end time. In contrast to meetings 
of another gathering of a number of people is important, 
but a purpose of the invent, which requires certain 
sources (e.g. a film projector, a certain location, etc.) 
which are available only at certain places. Therefore an 
event happens at a certain location. A user has to get 
to this location from the current location which usually 
takes some time. Furthermore resources like transpor- 
tation means maybe necessary. Events are attended by 
a certain number of people. Events can be described as 
a structure like: 

[0027] Event purpose, location, date, start time, dura- 
tion, attendees. 

[0028] A "template" is an event specification which 
consists of a number of specified attributes. An example 
of a template is: 

"film performance", Hedelfinger Str. 61+5 km, 24.1 0.00, 
18:00 GMT 

[0029] A "query" is a task to select a synchronously, 
i.e. while the user is waiting for the result. 
[0030] A "standing order" is a task to select events to 
inform the user about the occorns of these events as 
synchronously, i.e. while the user is disconnected to the 
system. 

[0031] Now, the components of a system for imple- 
menting the present invention will be explained for sev- 
erance to Figure 1 . 

[0032] A query management module 1 2 manages the 
queries and standing orders of users. In case of a query, 
the query management module receives this task from 
a presentation adaptation and interaction module (PI- 
AM) 6, asks the event gathering module 9 for events 
fitting into the template of the task, and sends these 



events to a selection and ordering module 10. After hav- 
ing received the results from the selection and ordering 
module 10, the query management module 12 forwards 
them to the PIAM 6 for display on a mobile communica- 
tion's device. To allow some interaction steps, the query 
management module 12 stores all data concerning the 
query in order to react to the user's interactions. There 
are two possible interaction steps. If a user accepts 
events proposed by the system, these events are en- 
tered into the calendar module 5 and the query is re- 
processed by sending again the events to the selection 
and ordering module 1 0 etc. As there are now more time 
restrictions, the result returned from the selection and 
ordering module 10 to the query management module 
10 might differ from the first step. If a user removes 
(waives) an event in the calendar module 5, the query 
management module 12 is notified and the query is re- 
processed to generate again new results returned from 
the selection and ordering module 10 to the query man- 
agement module 12. 

[0033] In the case of a standing order the query man- 
agement module 12 receives this task from the PIAM 6. 
It asks the event gathering module 9 to inform the query 
management module 12 in case of the occurrence of an 
event fitting into the template. The processing of this 
task is then stopped, but all data concerning the task is 
stored in the query management module 12. As soon 
as the event gathering module 9 notifies the query man- 
agement 1 2 on the occurrence of corresponding events, 
the query management module 12 sends the events to 
the selection and ordering module 10, receiving in turn 
the result which is a list of accessible events. The query 
management module 12 asks the presentation adapta- 
tion and interaction module 6 (PIAM) to inform the user 
on the result using the means the user selected. 
[0034] Finally the query management module 1 2 for- 
wards view selection information from the PIAM 6 to the 
context management module 7 when appropriate. 
[0035] In the following the function of the event gath- 
ering module 9 will be explained. This component gath- 
ers events and delivers sets of events that match a given 
template. There are several possibilities for the event 
gathering module 9 to gather events. One is to search 
appropriate information sources when events are need- 
ed, e.g. by using a search engine in the Internet 3 by 
consulting event web pages in the Internet 3. Another 
possibility is to subscribe to appropriate event sources, 
such that the event gathering module 9 is informed on 
the occurrence of new events. In order to react queries 
quickly, the event gathering module 9 can proactively 
search information sources (Internet 3 etc.) even with- 
out already knowing tasks. Thereto it can employ an 
own event database 1 7 to store events. In order to allow 
third parties to directly insert events manually, the event 
gathering module 9 can offer a manual input interface 
14 to do so. 

[0036] In case of a query the event gathering module 
9 receives a template from the query management mod- 
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ule 12 and answers it by returning a list of accessible 
events that fit into the template. In case of a standing 
order the event gathering module 9 receives a template 
from the query management module 12. As soon as the 
event gathering module 9 finds an event that fits into the 5 
template, it informs the query management module 12 
by returning a list of events that fit into the template. 
[0037] To fulfil its task the event gathering module 9 
can access a location database 8 in order to determine 
the location of and the distance to retrieved events. After 10 
having accessed the location database 8, every location 
entry in an event is extended by the geographic position 
of the location. Therefore the geographic position can 
e.g. be stored along with the event entry in the event 
database 17. 15 
[0038] The location database 8 is able to associate 
positions to symbolic (logic) location data as provided 
in the events. Such an association can be e.g.: 
"Gloria 1" = 34.00078N, 4.8901W 134.3 Meter). 
[0039] The first string denotes the symbolic (logic) 20 
name. The second part contains the graphic position e. 
g. in the WGS 84 format. Symbolic (logic) names can 
include names a location is known under ("MQnchener 
HofbrSuhaus"), an address ("Hedelfingerstr. 61") and 
other references to locations. Symbolic (logic) names 25 
are delivered by the event gathering module 9. The lo- 
cation database 8 answers such a request with the cor- 
responding geographic position. 
[0040] Now the function and operation of the selection 
ordering module (SOM) 1 0 will be explained. This com- 30 
ponent gets a set of events from the query management 
module 12 and selects and orders events aeon to a set 
of attributes. It answers to the query management mod- 
ule 12 by returning an ordered list of events. The set of 
attributes is requested of the context management mod- 35 
ule 7. It consists of an open set of data like: 

User preferences like 

event categories *o 
key words 

names of preferred participants (and their 
roles) 

preferred locations 

45 

• open time/location slots. 

[0041] In order to determine the time distance of and 
the way to events, the selection and ordering module 1 0 
can access the navigation module 11.lt requests these so 
data by delivering the a start in target location of possible 
transportation means. 

[0042] A description of the way and an estimation of 
the time needed in returned from the navigation module 
7. 55 
[0043] Navigation module 11 is connected to a posi- 
tion determination means such as e.g. a GPS. The po- 
sition determination means 1 5 can be furthermore con- 



nected to the query management module 12. The nav- 
igation module 11 can compute path to go from location 
to another one, resulting in a description of the way and 
the time necessary given a set of possible transportation 
means. 

[0044] The Context Management Module 7 gathers 
and stores context data and delivers them to the SOM 
10 in order to configure the selection and ordering proc- 
ess and to the PIAM 6 in order to configure the presen- 
tation adaptation and the interaction process. Context 
data might include: 

• the location of the user 

• data and time at the location of the user 

• the temperature at the location of the user 

• personal user data like his/her schedule 

• the history of his/her service usage 

• the actual condition of the network the user con- 
nects to 

• the actual condition of the user device 

• the user profile (e.g. age, gender, nationality, and 
user preferences) 

• the abilities of the user device 

• the social situation the user currently experiences. 

[0045] Parts of these data are collected from the CM 
5. 

[0046] When in "learning mode" the CMM 7 tries to 
gather user profile information automatically by exam- 
ining the interactions of the user with the service (see G 
in Figure 1 ), and , when possible, also by watching other 
Internet usage of this user outside the service. This in- 
formation is again stored inside the CMM 7. 
[0047] To allow users to use different sets of context 
data (e.g. to have different preferences according to the 
mode (business trip or holiday journey)), context data 
sets can be organised into different "views". The user is 
able to select these views using the PIAM 6 (which in- 
forms the QMM 12, which finally informs the CMM 7 
about the currently selected view). When delivering con- 
text information, the currently selected view is used. 
[0048] The Presentation Adaptation & Interaction 
Module PIAM 6 presents the results of queries and 
standing order to a user. This presentation is adapted 
according to context data like: 

• Type of the used device 

• the actual condition of the network 

• and so on 

[0049] Additionally, the PIAM 6 allows the user to do 
the following things: 

• enter a new request 

The user can specify all relevant attributes and 
modes of presentation (e.g. concerning sorting etc.) 
This results in a query that is sent to the QMM 12. 
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• enter a new standing order 

The user can specify all relevant attributes. 
This results in a query that is sent to the QMM12. 

• modify a standing order 

This is done by requesting a standing order 
from the QMM 12 and let the user modify it. The 
standing order is then resent to the QMM 12. 

• watch the results of requests or standing orders 

• accept an event of an event list 

In case of acceptance, the event is entered into 
the CM 5, then the QMM 12 is notified in order to 
get a new result that considers the new time/loca- 
tion restrictions that result from that choice. 

• select a view 

• select notification means 

[0050] Additionally, the PIAM 6 is able to send notifi- 
cations to offline users when the system detected an 
event that fits into a standing order. 
[0051] The calendar module 5 presents a calendar- 
like presentation to the user. Events the user has ac- 
cepted are entered into this calendar. In case of e.g. a 
change of mind or when exploring alternatives, a user 
can also waive accepted events in the calendar. In this 
case, the Query Management Module 12 is informed. 
To integrate into an existing office environment, the cal- 
endar module can be an existing product (e.g. Microsoft 
Outlook) as long as other programs can enter events 
and as long as other programs can sense the removal 
of events in the calendar. 

[0052] Additionally, the calendar is one source of in- 
formation for the context management system. 

Flows inside the system 

A query is processed 

[0053] The user starts a query process at the PIAM 6. 
The user enters a query at the PIAM 6, thus specifying 
e.g. the date, time, and location of the events to get. The 
PIAM 6 produces a template out of that and sends it, 
together with other data (e.g. presentation options, and 
the view to use) to the QMM 12. The QMM 12 creates 
a query entry and stores it. Afterwards, it sends the tem- 
plate to the EGM 9. The EGM 9 gathers events that fit 
into that template, e.g. by using its internal database. It 
also uses the LD 8 to determine whether an event fits 
into the template. Finally, it extends the events that fit 
into the template with the geographic positions gathered 
from the LD 8. This set of events is returned back to the 
QMM 12, where it is stored in the query entry. The QMM 
12 sends this set to the SOM 10. The SOM 10 applies 
its selection and ordering algorithm using data gathered 



from the CMM 7. To determine, in which time events can 
be reached, the SOM 10 uses the NM 11 which also 
delivers a description of the ways to reach the event. 
This description also extends the events. The SOM 10 

5 then returns an ordered list of events back to the QMM 
12. The QMM 12 sends this list to the PIAM 6, where it 
is presented to the user by applying the presentation ad- 
aptation mechanisms using context data from CMM 7. 
[0054] The user is now able to accept events from that 

10 list or remove events in the calendar. 

[0055] After having finished the query, the user stops 
the query process. 

The user accepts an event 

15 

[0056] If the user accepts an event in the PIAM 6, the 
event is sent to the CM 5 where it is entered into the 
calendar of that user. Additionally, the PIAM 6 sends the 
acceptance notification to the QMM 12, which in turn 

20 starts the selection and ordering process by sending the 
SOM 10 the set of event received before from the EGM 
9, but where the accepted event has been removed. As 
the accepted event further restricts the time/location 
availability of the user, another list of events might result 

25 from this process (the SOM 10 will know of this restric- 
tion as it receives these context data from the CMM 7, 
which, in turn, queries the CM 5). As above, the new list 
of events is presented to the user, and the user again 
can accept an event. 

30 

The user waives an event 

[0057] Events in the CM 5 (i.e. accepted events) can 
be waived by the user at any time. In this case the event 

35 is removed from the user's calendar by the CM 5. If no 
query is currently processed, no further steps are taken. 
If currently a query is processed and the waived event 
is one that originated from that query, this event is sent 
to the QMM 12 and the whole query process is re-start- 

40 ed. The only difference is that the event is again added 
to the event set stored at the QMM 1 2. If currently a que- 
ry is processed and the waived events does not origi- 
nate from that query process, the complete query proc- 
ess is started again by the QMM 12, i.e. also the EGM 

45 9 is asked for events that fit into the query template. 

A standing order is entered 

[0058] The user specifies a standing order. at the Pl- 
50 AM 6 in a similar way as he/she specifies a query with 
the one difference that also the communication means 
is specified that shall be used to inform the user about 
the occurrence of a corresponding event. The PIAM 6 
then sends this standing order to the QMM 12, where a 
55 standing order entry is generated. Finally, the QMM 12 
sends the corresponding template to the EGM 9. 
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A standing order is processed 

[0059] If the EGM 9 finds one or more events that fit 
to the template of the standing order (using the LD 8 in 
the same way as with queries), it sends these events to 
the QMM 12, specifying the standing order they belong 
to. The QMM 12 then starts the selection and ordering 
process in the same way as in the query process. When 
the QMM 12 sends the event list to the EGM 9, it also 
adds the communications means specification selected 
by the user. Finally, the user is notified about the event 
list using the selected communications means by the 
EGM 9. The user is then able to connect to the system 
and to interact in the same way as during a query (i.e. 
accepting and waiving events). 
[0060] In the following data structures for the system 
will be explained. 

[0061] One data structure is the event and event tem- 
plate, respectively, as they determine which kinds of 
events can be found. As described above, events mainly 
consist of 6 elements, namely: 

• event purpose 

• location 
date 

• start time 

• duration 

• list of attendees 

where the event purpose might be described with a 
standardised language (ontology). The location can be 
described either by a geographic position or a symbolic 
name that can be replaced by the LD 8 with a geographic 
position. 

[0062] Event templates have to offer possibilities to 
specify these elements in a fuzzy way. Per element, 
these possibilities include, apart from let an element un- 
specified (denoted by an "*"): 

Event purpose 

[0063] Here the problem is that we may have general 
and more specialised categories like "performance" - 
"opera". Therefore we need something like a tree of cat- 
egories, so an event can be described by higher-level 
categories. Additionally, some purposes should be de- 
scribed by several categories, therefore we need a list 
of categories describing an event. 
[0064] It is obvious that we need parameters for this 
element, for e.g. specifying a certain film (like "Casa- 
blanca"). 

Location 

[0065] This element contains the geographical posi- 
tion of the event. 

[0066] Additionally, this element may contain an 
"thresholds" attribute that specified the range of x me- 



ters around this data for events that fit into that template. 
Date 

5 [0067] This element contains the date of the event. 
[0068] Additionally, this element may contain an 
"thresholds" attribute that specified the range of x days 
around this data for events that fit into that template. 



[0069] This element contains the start time of events. 
If have to make sure that also the time zone of this time 
is encoded in order to prevent miscalculations. 
f5 [0070] Additionally, this element may contain an 
"thresholds" attribute that specified the range of x sec- 
onds around this data for events that fit into that tem- 
plate. 



[0071] This element contains a duration e.g. in min- 
utes. 

[0072] Additionally, this element may contain an 
25 "thresholds" attribute that specified the range of x sec- 
onds around this data for events that fit into that tem- 
plate. 

List of attendees 

30 

[0073] This element contains references to persons. 
Ordering 

35 [0074] Each of the elements above might additionally 
contain an "orderingm" attribute that denotes that this 
element shall also be used for order the event set. The 
parameter n of this attributes denotes the rank of the 
ordering element. 

40 

Examples of event templates 
[0075] 

45 What to do now and here? 

(event purpose=*; 

location=ORDER: 1 ,34 .7894 N .85993W.374m , 
threshold: 10000m; 
so date =19.10.00; 

start=ORDER:2,13:41 MET threshold: 
3600sec; 

duration=ORDER:3, *; 
list of attendees = *) 

55 

Planning of a day out in Paris 

(event purpose=*; 



w Start time 



20 Duration 
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location=ORDER:1,17.7894N.81.993W.374m, 

threshold: 10000m; //was "Paris.Boulevard St. 

Germain" 

date = 15.11.00; 

start=ORDER:2,8:00 MET, threshold: 5 
36000sec; 

duration =ORDER:3, *; 
list of attendees=*) 

A true fan 

(event purpose = Music Performance of "The 
Jellybabies"; 

location=ORDER:1,34.7894N.85.993W.374m, 
threshold: 50000m; 
date=*; 
start=*; 
duration = *; 
list of attendees = *) 

Specification of queries and standing orders 

[0076] The easiest way to implement this aspect is 
certainly to offer the user an interface where he/she can 
specify every single element with all the given possibil- 
ities. Unfortunately, this would require the knowledge of 
how to specify these things. Therefore, this possibility is 
only suited for expert users. Additionally, especially mo- 
bile devices like mobile phone normally do offer only 
very restricted input possibilities (as they rarely include 
a keyboard and feature only small displays). 
[0077] Normal users or users using this type of devic- 
es can use a restricted interface that allow to choose 
only of a few possibilities. One of these possibilities is 
the "what to do now and here" mode, where the system 
generates a template as described above using the cur- 
rent time and location taken from the CMM (which, in 
turn, might have sensed these information at the user's 
device). 

[0078] The easiest way to interact with the system is 
to allow active suggestions based on implicitly gathered 
profiles as then the user does not have to further specify 
queries or preferences. Another possibility to help users 
specifying queries and standing order is to use default 
values also stored in the CMM. 

Gathering events: 

[0079] Events can be entered directly via manual in- 
put. In this case all relevant information can be gathered 
easily using an appropriate form. 
[0080] Events can be also gathered by searching ap- 
propriate information sources, e.g. web pages, e-mails 
(if this is appropriate under privacy aspects), and data- 
bases. Especially in the web, there are many pages that 
offer event data in a human-readable form, e.g. http:// 
www.stuttgart.de/sixcms/list.php37page id =25. There 
are also some databases in the Internet, e.g. http ://www. 



lift-online. com/cgi/setkalender.pl where event data can 
be queried automatically. As there is no standard for of- 
fering such data, and as the audience for event data is 
normally a human one, most information sources fea- 
ture an own event data format, often suited for human 
use. Therefore, an architecture that wants to use these 
information sources has to cope with the different for- 
mats, which might be also the subject of frequent, un- 
announced changes. The EGM 9 has then simply to 
translate the event data format of the information sourc- 
es to the one used in the system. 
[0081] In the near future, such events might be offered 
on sources like web servers as XML documents. In this 
case, the EGM has to know and to understand the cor- 
responding DTDs. 

[0082] Events are stored into an event database 17 
inside or outside of the EGM 9, e.g. in XML form, in order 
to quickly react on queries by the QMM 12. 

Getting events from the EGM 

[0083] To return a set of events that fit into a given 
event template, the EGM 12 has to consider all elements 
of an event template. An element qualifies for being in- 
cluded in the event set, all of its elements have to qualify. 
An element qualifies if it is unspecified ("*"). Whether a 
specified element qualifies, depends on the element: 

Event purpose 

[0084] This element qualifies if the specified category 
is a predecessor in one of the category hierarchies of 
the event, and if the parameter, if specified, are equal. 

Location 

[0085] This element qualifies if the geographical loca- 
tion of the event (as determined by the LD 8) lies in the 
range specified by the event template. 

Date 

[0086] This element qualifies if the date of the event 
lies in the range specified by the event template. 

Start time 

[0087] This element qualifies if the date of the event 
lies in the range specified by the event template. 

Duration 

[0088] This element qualifies if the date of the event 
lies in the range specified by the event template. 

List of attendees 

[0089] This element qualifies if the list of persons 
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specified in the event template are contained in the list 
of attendees of the event. 

Selection and Ordering Algorithm 

[0090] The selection and ordering algorithm is a two- 
stage process. In the first stage events out of the incom- 
ing event set are selected according to some criteria re- 
ceived from the CMM determined by a view selected by 
the user. One of these criteria is the calendar of the us- 
ers: only events are selected that do not collide with ex- 
isting entries. Another criteria is the time needed to 
reach the location of an event. Computed by the NM 11 , 
this time need is considered when events are selected 
that fit into the time range of the event template. 
[0091] In the second stage, the events are ordered ac- 
cording to the ordering criteria. These criteria are spec- 
ified in the event templates. 

Presentation adaptation 

[0092] The presentation is adapted inside the PIAM 6 
towards the user in relation to a whole number of factors. 
The presentation process consists of at least three stag- 
es (see Figure 2) 

[0093] The first stage is the "data adaptation" which 
adapts the presentation according to the characteristics 
of the data (i.e. the events) itself. If an event is e.g. near- 
by, just the event description and the location of the 
event might be displayed, if an event is not nearby, but 
in the same city, additionally the public transport data 
(time tables, ways to a station) is displayed, etc. These 
adaptation can be realised e.g. by using a rule mecha- 
nism that is able to specify things like "if (event.iocation 
= "nearby") then show (event.desription.event.loca- 
tion)" or "if (event.iocation = "intown") then show (event, 
description, event, location, event, transportation, time- 
tables)". 

[0094] The second stage is the "user adaptation" 
which adapts the presentation in relation to the user. 
This includes adjustments according to the explicit set- 
tings by the user, his/her preferences that have been 
learned by the system, etc. 

[0095] The third stage is the "device adaptation" 
which adapts the presentation according to the charac- 
teristics of the actual user device and the data connec- 
tion to that device. This adaptation includes adjustments 
to things like the screen size, the colour abilities, the 
needed presentation format (e.g. HTML or WML), the 
actual bandwidth, and the condition of the network. 
[0096] The components of the system could be dis- 
tributed as depicted in Figure 3. The PIAM 6 component 
can be decomposed into a system-side PIAM module 
6, and a user-device-side client program 4. The latter 
might consist simply of a web or a WAP browser. Alter- 
natively, it might consist of a special client program that 
handles interaction of the user with the system. The CM 
5 might reside on the user device; in this case it might 



consist of an existing calendar program (like Microsoft 
Outlook). 

[0097] The overall system can be realised as a serv- 
ice of a multi-access service portal. 

5 [0098] The EGM 9 gathering process can be realised 
using translator and adaptor components that translate 
events from the format at the source into the format that 
is used inside the system, and that encapsulate the que- 
rying process of the event source, respectively. It can 

10 be expected that events can be accessed in the web in 
an XML-based format in the future. 
[0099] The EGM 9 can employ a SQL database to 
store the events gathered. The Event templates can 
then be realised by SQL statements that are used to be 

15 executed in the EGM database. 

[0100] The CM 5 can be located either on the user's 
device, in the system, or on another computer in a con- 
nected network. The CM 5 can be e.g. realised using 
Microsoft Outlook using its COM interface on the user's 

20 device. 



Claims 

25 1. A method for managing event information data, 
the method comprising the following steps: 

inquiring the current time (16) and the current 
geographical position (15) of a mobile commu- 

30 nications device (1), 

using the current time (16) and geographical 
position (15) information for a template to query 
(12) an event source (9), the event source (9) 
containing event entries parameterized by their 

35 category, time and location, 

calculating a list of events accessible for a user 
of the mobile communications device (1 ) taking 
into account the differences between the start- 
ing time and the location of an event and the 

40 current time and position of the mobile commu- 

nications device (1) and 
presenting (6) the list of accessible events on 
the mobile communications device (1). 

45 2. A method according to claim 1 , 
characterized in that 

the step of calculating a list of accessible events 
comprises the step of taking into account transpor- 
tation ressources from the current position of the 
50 mobile communications device (1 ) to the location of 
an event. 

3. A method according to claim 1 or 2, 
characterized in that 
55 furthermore profile information of the user of the 
mobile communications device (1) is part of the 
template to query (12) the event source (9). 
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4. A method according to claim 1 , 2 or 3, 
characterized in that 

at least for a part of the accessible events a trans- 
portation information for possible ways to get from 
the current position of the mobile communications 
device (1 ) to an event location is calculated (11 ) and 
presented. 

5. A method according to anyone of the preceding 
claims, 

characterized in that 

the list of accessible events is presented (6) dynam- 
ically, i.e. the list of accessible events is updated to 
generate a list of remaining accessible events each 
time the user of the mobile communications device 
(1) accepts an event. 

6. A method according to anyone of the preceding 
claims, 

characterized in that 

accessible events accepted by the user of the mo- 
bile communications device (1) are automatically 
transferred as entries to an electronic calendar file 
(5). 

7. A method according to anyone of the preceding 
claims, 

characterized in that 

the user of the mobile communications device (1) 
can create events for the list of accessible events 
and/or for the event source (9). 

8. A method according to claim 7, 
characterized in that 

the user can create (14) events by customizing 
manually generic events proposed by the mobile 
communications device (1). 

9. A method according to anyone of the preceding 
claims, 

characterized by 

a learning mode in which the mobile communica- 
tions device (1 ) learns event preferences of the user 
by evaluating the interaction with the user. 

10. A method according to anyone of the preceding 
claims, 

characterized in that 

the user can preconfigure standing orders for 
events such that corresponding events are auto- 
matically selected when retrieved in the event 
source (9). 

11. A method according to anyone of the preceding 
claims, 

characterized in that 

the event entries of the event source (9) are gener- 
ated automatically by searching a network (3). 



12. A computer software program product, 
characterized in that 

it implements a method according to anyone of the 
preceding claims when run on a mobile communi- 
5 cation device (1). 

13. A mobile communications device having an event 
managing module, 

the event managing module (1, 2) comprising: 

10 

means (1 5, 1 6) for determining the actual time 
and the current geographical position of the 
mobile communications device (1), 
means for querying (12) an internal and/or ex- 

15 ternal event source (9) containing event entries 

parameterized by their category, time and loca- 
tion, wherein the querying is performed on the 
basis of a template containing at least the cur- 
rent time and geographical position of the mo- 

20 bile communications device (1 ), 

means for calculating a list of events accessible 
for a user of the mobile communications device 
(1 ) taking into account the differences between 
the starting time and the location of an event 

25 and the current time and position of the mobile 

communications device (1 ) and 
- means for presenting (6) the list of accessible 
events. 

30 14. A mobile communications device according to claim 
13, 

characterized in that 

the means for calculating a list of accessible events 
take into account transportation ressources from 
35 the current position of the mobile communications 
device (1) to the location of an event. 

15. A mobile communications device according to claim 
13 or 14, 
40 characterized in that 

the template used by the querying means (12) fur- 
thermore comprises profile information of the user 
of the mobile communications device (1). 

45 16. A mobile communications device according to any- 
one of claims 13 to 15, 
characterized in that 

it furthermore comprises a navigation module (11) 
for calculating and presenting possible 
so ways to get from the current position of the mobile 
communications device (1) to the location of an 
event. 

17. Mobile communications device according to any- 
55 one of claims 1 3 to 1 6, 
characterized by 

a computing means (6) for updating the list of ac- 
cessible events dynamically to generate a list of re- 
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maining accessible events each time the user of the 
mobile communications device (1) accepts an 
event. 

18. Mobile communications device according to any- 
one of claims 13 to 16, 
characterized by 

means (12) for automatically transferring accessi- 
ble events accepted by the user of the mobile com- 
munications device as entries to an electronic cal- 
endar file (5). 



PatentansprCiche 

1. Verfahren zur Verwaltung von Ereignisinformati- 
onsdaten, 

wobei das Verfahren die folgenden Schritte auf- 
weist: 

- Abfragen der laufenden Zeit (16) und der lau- 
fenden geografischen Position (15) eines mo- 
bilen Kommunikationsgerats (1), 

- Verwenden der Information uber die laufende 
Zeit (1 6) und geografische Position (1 5) fur eine 
Schablone zur Abfrage (12) einer Ereignisquel- 
le (9), wobei die Ereignisquelle (9) Ereignisein- 
gaben enthait, die durch ihre Kategorie, Zeit 
und ihren Ort parameterisiert sind, 

- Berechnen einer Liste von Ereignissen, die fQr 
einen Benutzer des mobilen Kommunikations- 
gerats (1 ) bei BerQcksichtigung der Differenzen 
zwischen der Startzeit und dem Ort eines Er- 
eignisses und der laufenden Zeit und Position 
des mobilen Kommunikationsgerats (1) zu- 
greifbar sind, und 

- PrSsentieren (6) der Liste zugreifbarer Ereig- 
nisse auf dem mobilen Kommunikationsgerat 
(1). 

2. Verfahren nach Anspruch 1 , 
dadurch gekennzeichnet, dass 

der Schritt der Berechnung einer Liste zugreifbarer 
Ereignisse den Schritt einer BerQcksichtigung von 
Transportressourcen von der laufenden Position 
des mobilen Kommunikationsgerats (1 ) zum Ort ei- 
nes Ereignisses aufweist. 

3. Verfahren nach Anspruch 1 Oder 2, 
dadurch gekennzeichnet, dass 

aufierdem Profi I information des Benutzers des mo- 
bilen Kommunikationsgerats (1 ) Teil der Schablone 
zur Abfrage (12) der Ereignisquelle (9) ist. 

4. Verfahren nach Anspruch 1 , 2 oder 3, 
dadurch gekennzeichnet, dass 

wenigstens fQr einen Teil der zugreifbaren Ereignis- 
se eine Transportinformation fur mOgliche Wege, 



um von der laufenden Position des mobilen Kom- 
munikationsgerats (1 ) zu einem Ereignisort zu kom- 
men, berechnet (11) und prasentiert wird. 

5 5. Verfahren nach einem der vorhergehenden Anspru- 
che, 

dadurch gekennzeichnet, dass 

die Liste zugreifbarer Ereignisse dynamisch pra- 
sentiert wird (6), das heifit die Liste zugreifbarer Er- 
10 eignisse aktualisiert wird, um eine Liste bleibender 
zugreifbarer Ereignisse jedes Mai, wenn der Benut- 
zer des mobilen Kommunikationsgerats (1) ein Er- 
eignis akzeptiert, zu erzeugen. 

15 6. Verfahren nach einem der vorhergehenden Anspru- 
che, 

dadurch gekennzeichnet, dass 

vom Benutzer des mobilen Kommunikationsgerats 
(1 ) akzeptierte zugreifbare Ereignisse automatisch 
20 als Eingaben in eine elektronische Kalenderdatei 
(5) ubertragen werden. 

7. Verfahren nach einem der vorhergehenden Anspru- 
che, 

25 dadurch gekennzeichnet, dass 

der Benutzer des mobilen Kommunikationsgerats 
(1) Ereignisse fQr die Liste zugreifbarer Ereignisse 
und/oder fQr die Ereignisquelle (9) erzeugen kann. 

30 8. Verfahren nach Anspruch 7, 

dadurch gekennzeichnet, dass 

der Benutzer Ereignisse durch manuelle kunden- 
spezifische Anpassung auswahlbarer Ereignisse, 
die vom mobilen Kommunikationsgerat (1) vorge- 
35 schlagen werden, erzeugen kann. 

9. Verfahren nach einem der vorhergehenden AnsprQ- 
che, gekennzeichnet durch 

einen Lernmodus, bei dem das mobile Kommuni- 
40 kationsgerat (1) Ereignispraferenzen des Benut- 
zers durch Bewerten der Interaktion mit dem Be- 
nutzer lernt. 

1 0. Verfahren nach einem der vorhergehenden Anspru- 
45 che, 

dadurch gekennzeichnet, dass 
der Benutzer stehende Ordnungen fur Ereignisse 
derart vorkonfigurieren kann, dass korrespondie- 
rende Ereignisse automatisch gewahlt werden, 
50 wenn sie in der Ereignisquelle (9) wieder aufgefun- 
den werden. 

1 1 . Verfahren nach einem der vorhergehenden Anspru- 
che, 

55 dadurch gekennzeichnet, dass 

die Ereigniseingaben der Ereignisquelle (9) durch 
Suchen eines Netzes (3) automatisch erzeugt wer- 
den. 
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12. Computersoftwareprogrammprodukt, 
dadurch gekennzeichnet, dass 

es ein Verfahren gemaft einem der vorhergehenden 
Anspruche implementiert, wenn es auf einem mo- 
bilen Kommunikationsgerat (1) ISuft. 

13. Mobiles Kommunikationsgerat, das ein Ereignis- 
verwaltungsmodul aufweist, 

wobei das Ereignisverwaltungsmodul (1, 2) auf- 
weist: 

eine Einrichtung (15, 16) zur Bestimmung der 
aktuellen Zeit und der laufenden geografischen 
Position des mobilen Kommunikationsgerats 
(1). 

eine Einrichtung zur Abfrage (12) einer internen 
und/oder externen Ereignisquelle (9), die durch 
ihre Kategorie, Zeit und ihren Ort parameteri- 
sierte Ereigniseingaben enthait, wobei die Ab- 
frage auf der Basis einer Schablone, die wenig- 
stens die laufende Zeit und geografische Posi- 
tion des mobilen Kommunikationsgerats (1) 
enthait, ausgefuhrt wird, 
eine Einrichtung zur Berechnung einer Liste 
von Ereignissen, die fur einen Benutzer des 
mobilen Kommunikationsgerats (1 ) bei BerOck- 
sichtigung der Differenzen zwischen der Start- 
zeit und dem Ort eines Ereignis und der laufen- 
den Zeit und Position des mobilen Kommuni- 
kationsgerats (1) zugreifbar sind, und 
eine Einrichtung zum PrSsentieren (6) der Liste 
zugreifbarer Ereignisse. 

14. Mobiles Kommunikationsgerat nach Anspruch 13, 
dadurch gekennzeichnet, dass 

die Einrichtung zur Berechnung einer Liste 
aus zugreifbaren Ereignissen Transportressourcen 
von der laufenden Position des mobilen Kommuni- 
kationsgerats (1) zum Ort eines Ereignisses be- 
rucksichtigt. 

15. Mobiles Kommunikationsgerat nach Anspruch 13 
Oder 14, 

dadurch gekennzeichnet, dass 

die von der Abfrageeinrichtung (12) verwen- 
dete Schablone aulierdem Profilinformation des 
Benutzers des mobilen Kommunikationsgerats (1 ) 
aufweist. 

16. Mobiles Kommunikationsgerat nach einem der An- 
sprtlche 13 bis 15, 

dadurch gekennzeichnet, dass 

es aufierdem ein Navigationsmodul (11) zur 
Berechnung und Prasentierung m&glicher Wege, 
urn von der laufenden Position des mobilen Kom- 
munikationsgerat (1 ) zum Ort eines Ereignisses zu 
kommen, aufweist. 



17. Kommunikationsgerat nach einem der Anspruche 
13 bis 16, gekennzeichnet durch: 

eine Berechnungseinrichtung (6) zur dynami- 
5 schen Aktualisierung der Liste zugreifbarer Er- 

eignisse, urn eine Liste bleibender zugreifbarer 
Ereignisse jedes Mai, wenn der Benutzer des 
mobilen Kommunikationsgerats (1 ) ein Ereig- 
nis akzeptiert, zu erzeugen. 

10 

18. Mobiles Kommunikationsgerat nach einem der An- 
sprOche 13 bis 16, 

gekennzeichnet durch: 

15 eine Einrichtung (12) zur automatischen Qber- 

tragung zugreifbarer Ereignisse, die vom Be- 
nutzer des mobilen Kommunikationsgerats ak- 
zeptiert sind, als Eingaben in eine elektroni- 
sche Kalenderdatei (5). 

20 

Revendications 

1. Procede pour gerer des donnees d'information 
25 d^venement, le procede comprenant les etapes qui 

suivent : 

interrogation du temps courant (16) et de la po- 
sition geographique courante (15) d'un dispo- 

30 sitif de communication mobile (1 ) ; 

utilisation de I'information de temps courant 
(16) et de position geographique courante (15) 
pour un gabarit afin de questionner (12) une 
source d'evenements (9), la source d'evene- 

35 ments (9) contenant des entrees d'evenement 

parametrees selon leurs categories, leur temps 
et leurs localisations ; 

calcul d'une liste d'evenements accessibles 
pour un utilisateurdu dispositif de communica- 
40 tion mobile (1 ) en prenant en compte les diffe- 

rences entre le temps de debut et la localisation 
d'un evenement et le temps courant et la posi- 
tion du dispositif de communication mobile (1 ) ; 
et 

45 presentation (6) de la liste d'evenements ac- 

cessibles sur le dispositif de communication 
mobile (1). 

2. Procede selon la revendication 1 , caracterise en 
so ce que I'etape de calcul d'une liste d'evenements 

accessibles comprend I'etape de prise en compte 
de ressources de transport depuis la position cou- 
rante du dispositif de communication mobile ( 1 ) jus- 
qu'a la localisation d'un ev6nement. 

55 

3. Procede selon la revendication 1 ou 2, caracterise 
en ce qu'une information de profil supplementaire 
de Putilisateur du dispositif de communication mo- 



11 



21 



EP 1 241 830 B1 



22 



bile (1) est une partie du gabarit pour questionner 
(12) la source d'evenements (9). 

4. Procede selon la revendication 1, 2 ou 3, caracte- 
rise en ce qu'au moins pour une partie des evene- 
ments accessibles, une information de transport 
pour des facons possibles d'aller depuis la position 
courante du dispositif de communication mobile (1) 
jusqu'a une localisation d'evenement est calculee 
(11) et est presentee. 

5. Procede selon Tune quelconque des revendications 
prec6dentes, caracterise en ce que la liste d'eve- 
nements accessibles est presentee (6) de facon dy- 
namique, c'est-a-dire que la liste d'evenements ac- 
cessibles est mise a jour afin de generer une liste 
d'evenements accessibles restants chaque fois que 
I'utilisateur du dispositif de communication mobile 
(1 ) accepte un evenement. 

6. Procede selon Tune quelconque des revendications 
precedentes, caracterise en ce que des evene- 
ments accessibles acceptes par I'utilisateur du dis- 
positif de communication mobile (1 ) sont transferes 
de maniere automatique en tant qu'entrees sur un 
fichier de calendrier electronique (5). 

7. Procede selon Tune quelconque des revendications 
precedentes, caracterise en ce que I'utilisateurdu 
dispositif de communication mobile (1) peut creer 
des evenements pour la liste d'evenements acces- 
sibles et/ou pour la source d'evenements (9). 

8. Procede selon la revendication 7, caracterise en 
ce que I'utilisateur peut creer (14) des evenements 
en personnalisant manuellement des evenements 
gen6riques qui sont proposes par le dispositif de 
communication mobile (1 ). 

9. Procede selon I'une quelconque des revendications 
precedentes, caracterise par un mode apprentis- 
sage dans lequel le dispositif de communication 
mobile (1) apprend des preferences d'evenement 
de I'utilisateur en evaluant Interaction avec I'utili- 
sateur. 

10. Procede selon Tune quelconque des revendications 
precedentes, caracterise en ce que I'utilisateur 
peut preconfigurer des ordres de survenue pour 
des evenements de telle sorte que des evenements 
correspondents soient selectionnes de maniere 
automatique lors d'une recherche dans la source 
d'ev6nements (9). 

1 1 . Procede selon I'une quelconque des revendications 
precedentes, caracterise en ce que les entrees 
d'evenement de la source d'evenements (9) sont 
generees de maniere automatique en recherchant 



un reseau (3). 

12. Produit de programme de logiciel d'ordinateur ca- 
racterise en ce qu'il met en oeuvre un procede se- 

5 Ion I'une quelconque des revendications preceden- 
tes lorsqu'il est d6roule sur un dispositif de commu- 
nication mobile (1). 

13. Dispositif de communication mobile qui comporte 
10 un module de gestion d'evenement, le module de 

gestion d'evenement (1 , 2) comprenant : 

un moyen (15, 16) pour determiner le temps 
reel et la position geographique courante du 

15 dispositif de communication mobile (1 ) ; 

un moyen pour questionner (12) une source 
d'ev6nements interne et/ou externe (9) qui con- 
tient des entrees d'evenement parametrees se- 
lon leurs categories, leur temps et leurs locali- 

20 sations, ou le questionnement est realis6 sur la 

base d'un gabarit qui contient au moins le 
temps courant et la position geographique cou- 
rante du dispositif de communication mobile 
(1): 

25 un moyen pour calculer une liste d'evenements 

accessibles pour un utilisateur du dispositif de 
communication mobile (1 ) en prenant en comp- 
te les differences entre le temps de debut et la 
localisation d'un evenement et le temps cou- 

30 rant et la position geographique courante du 

dispositif de communication mobile (1) ; et 
un moyen pour presenter (6) la liste d'evene- 
ments accessibles. 

35 14. Dispositif de communication mobile selon la reven- 
dication 13, caracterise en ce que le moyen pour 
calculer une liste d'evenements accessibles prend 
en compte des ressources de transport depuis la 
position courante du dispositif de communication 

40 mobile (1 ) jusqu'a la localisation d'un evenement. 

15. Dispositif de communication mobile selon la reven- 
dication 13, caracterise en ce que le gabarit qui 
est utilise par le moyen de questionnement (12) 

<5 comprend en outre une information de profil de I'uti- 
lisateur du dispositif de communication mobile (1). 

16. Dispositif de communication mobile selon I'une 
quelconque des revendications 13 a 15, caracteri- 
se? se en ce qu'il comprend en outre un module de na- 
vigation (11 ) pour calculer et presenter des facons 
possibles d'aller depuis la position courante du dis- 
positif de communication mobile (1 ) jusqu'a ia loca- 
lisation d'un evenement. 

55 

17. Dispositif de communication mobile selon I'une 
quelconque des revendications 13 a 16, caracteri- 
se par un moyen de calcul (6) pour mettre a jour la 
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liste d'evenements accessibles de maniere dyna- 
mique afin de generer une liste d'evenements ac- 
cessibles restants chaque fois que I'utilisateur du 
dispositif de communication mobile (1) accepte un 
evenement. 5 

18. Dispositif de communication mobile selon Tune 
quelconque des revendications 13 a 16, caracteri- 
se par un moyen (12) pour transferer de maniere 
automatique des evenements accessibles qui sont io 
acceptes par I'utilisateur du dispositif de communi- 
cation mobile en tant qu'entrees sur un fichier de 
calendrier electronique (5). 

15 
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